home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000054_news@newsmaster….columbia.edu _Sat Oct 4 19:41:20 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA23708
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 4 Oct 1997 19:41:20 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA21899
  7.     for kermit.misc@watsun; Sat, 4 Oct 1997 19:41:19 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!newsfeed.direct.ca!logbridge.uoregon.edu!news.bc.net!rover.ucs.ualberta.ca!alberta!not-for-mail
  9. From: Vladimir Alexiev <vladimir@cs.ualberta.ca>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Date: 04 Oct 1997 17:23:04 -0600
  13. Organization: University of Alberta, Computing Science
  14. Lines: 59
  15. Message-ID: <omraa16rl3.fsf@tees.cs.ualberta.ca>
  16. References: <k1c7kBQEU5Wv@cc.usu.edu> <omafgv99sa.fsf@tees.cs.ualberta.ca>
  17.     <XrKuqa+e0PBq@cc.usu.edu>
  18. NNTP-Posting-Host: tees.cs.ualberta.ca
  19. In-reply-to: jrd@cc.usu.edu's message of 1 Oct 97 17:38:37 MDT
  20. X-Newsreader: Gnus v5.0.15
  21. Xref: news.columbia.edu comp.protocols.kermit.misc:7822
  22.  
  23. In article <XrKuqa+e0PBq@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  24.  
  25. > > the fact remains that these apps can use emulated class 1 drivers, while
  26. > > Kermit can't. Sometimes worse is better.
  27. >     This looks more and more like an argument waiting to happen, due to
  28. > lack of specific information.
  29.  
  30. Talk by Michael Ringe <michael@thphys.physik.rwth-aachen.de> which is "built
  31. upon the WATTCP library" works with EPPPD which is a class 1 PPP driver.
  32. Kermit's TCP is also built over the WATTCP library (if information on WATTCP's
  33. site is correct), but I guess that Joe has introduced changes that make it
  34. incompatible with drivers emulating class 1 (Internet).
  35.  
  36. > I thought I explained the difficulties with a driver purporting to be
  37. > Ethernet but isn't; they are fundamental.
  38.  
  39. How do you explain then that that talk program works? I also tried
  40. successfully the telnet from NUPop over the same EPPPD driver, however NUPop
  41. is not WATTCP-based. Would you like me to test WATTCP FTP or a WATTCP-based
  42. telnet client (where is one)?
  43.  
  44. > > Well, these half measures prove to be adequate for other WATTCP apps.
  45. >     which are tailored for a point to point link, no doubt.
  46. I don't think so. I don't have an ethernet connection I can try them with, but
  47. their docs claim they work over ethernet too. It wouldn't make much sense if
  48. they didn't.
  49.  
  50. > > - there are apps that only support ethernet interfaces. Kermit couldn't
  51. > >   coexist with such apps because it demands a SLIP interface.
  52. >     Argumentative again. No, Kermit does not "demand" SLIP,
  53. If Kermit is to be used with a serial link (SLIP or PPP), the packet driver
  54. has to support class 6 (SLIP) interface. Obviously all SLIP drivers do, but
  55. only two out of the three freely available PPP drivers do (dosppp and
  56. MeritPPP, aka etherppp or ethernew), while ppppkt does not. More important
  57. however is that if one would like to use another TCP app together with Kermit,
  58. that app should also support class 6, because a driver can only run in one of
  59. the class modes that it supports at a time.
  60.  
  61. > but if the alternatives fail to meet specs then that is hardly Kermit's
  62. > fault.
  63. What spec does a working combination "class 1 PPP driver" - "class 1 app" fail
  64. to meet? You seem to assert that class 1 emulating serial drivers are
  65. impossible, yet there are at least 3 such: dosppp, MeritPPP, pppshare/pppdemo.
  66.  
  67. > > Is BOOTP impossible with a SLIP interface? How about DHCP?
  68. > Both use UDP over IP. How IP gets put onto the wire is another matter.
  69. Yes, I can't think of a good reason why BOOTP shouldn't work either, but the
  70. class 6 driver in dosppp (PPPD) doesn't support it for some reason.
  71.  
  72. > Please do keep in mind that both BOOTP and DHCP are sensitive to physical
  73. > address
  74. Why? Isn't it only critical for RARP (which resolves an Ether address to an
  75. IP address)? I guess it depends a lot on the remote side as well, because most
  76. often the remote gives us our IP.
  77.  
  78. > > How about Windows PPP drivers, do they support an Ethernet interface?
  79.  
  80. (Forget about this, my mind was probably clouded when I wrote it; Windows
  81. drivers are not packet drivers.)